除了redis, voltdb, h-store等，都会利用多核cpu，并尽量减少磁盘I/O的延迟，当然需要保证thread-safety

A concurrency control protocol需要保证正确性，其正确性的标准在于：

区别是：

Latch一般是由一个CPU提供的CAS(compare-and-swap)操作,CAS 的含义是“我认为原有的值应该是什么，如果是，则将原有的值更新为新值，否则不做修改，并告诉我这个值现在是多少”，就是比如设置一个值flag，当flag = false是，锁没有被其他人持有，这时可以将flag与true swap，并且这个compare and swap的操作是原子的，其他在执行compare时，就会卡住，直到第一个进程将flag的值swap回来。由三种实现latch的方法，它们都做了对于实现复杂度与执行时的效率之间的权衡：

Blocking OS Mutex 需要OS介入，OS唤醒与睡眠一个线程的操作比较浪费时间，但是这种方法会用阻塞队列(比spin lock好)，这样其他进程就不会一直占用cpu时间 两把锁？

Test-and-Set Spin Latch (TAS) 自旋锁，非常浪费cpu时间，即使一个进程进不了临界区，任然会持续占有cpu JAVA与GO中会使用TAS与Mutex结合的锁，先自旋，到达一定时间，在陷入内核 deschedule？

Reader-Writer Latches 一般基于前两者来实现，但是会区分读写模式，通过添加元数据，当然这需要DBMS花费更多的维护成本去避免Thread的饥饿

hash table的latch不会死锁，

B+树需要保证两个方面的并发问题：

从正确性的角度看，释放latch的顺序并不重要，但是从性能的角度看，比较重要，最好是先释放高层节点的锁，因为如果高层节点被加上write latch，会使得其他thread连read都不行

对于search与未优化版的一样，但是对于设计Write的操作，可以先用乐观锁，也就是假定需要发生节点合并与分裂的概率很低，全程使用read latch；当真正发生节点合并与分裂时，再终止重头来过，这一次使用悲观锁，也就是write latch

对于top to down的寻找leaf node,并不会发生deadlock，因为一个线程只能够从上到下的获取latch 但是leaf node scan会发生deadlock， 可以通过以下方法解决leaf node scan时的dealock

做标记和写33不是一样耗费时间吗，延迟的意义何在？

例子没看懂？